Using Indexed and Synchronous Events to Model and Validate Cyber-Physical Systems

ion of Input Signal Values. The TTM tool, like other model checking tools, cannot handle the real-valued monitored variables f NOPsp and calibrated nop signal[i]. Instead, based on the given constants mentioned above, we partition the infinite domains of these two monitored variables into disjoint intervals. First, the four possible constant values for f NOPsp have a fixed order and are bounded by constant low and high limits of the calibrated NOP signal. More precisely, we have 6 boundary cases to consider: k NOPLoLimit < k NOPLPsp < k NOPAbn2sp < k NOPAbn1sp < k NOPnormsp < k NOPHiLimit. Second, each of the four possible set points has an associated hysteresis band, whose lower boundary is calculated by subtracting the constant band size k NOPhys, resulting in 4 additional boundaries4 to consider: (a) k NOPLPsp− k NOPhys; (b) k NOPAbn2sp− k NOPhys; (c) k NOPAbn1sp− k NOPhys; and (d) k NOPnormsp− k NOPhys. Consequently, we have 10 boundary cases and 9 in-between cases (e.g., k NOPLoLimit < signal < k NOPLPsp) to consider. Accordingly, we construct a finite integer set cal nop that covers all the 19 intervals. For the purpose of modelling and verifying the NOP controller and sensors in TTM, we parameterize the system by a positive integer N denoting the number of dependant sensors. Version 1: Synchronizing Plant and Controller. We first present an abstract version of the model that couples the NOP controller and its plant by executing their actions synchronously. Figure 6 illustrates the structure of synchronization. The dashed box in Figure 6 indicates the set of synchronized modules instances: plant p, controller nop, and 18 sensors sensor i (i ∈ 0 ..17). sensor_0: NOP_SENSOR sensor_0.respond p: PLANT p.generate out f_NOPsp out c_NOPparmtrip out f_NOPsentrip[0] out calibrated_nop_signal[0] sensor_17: NOP_SENSOR sensor_17.respond out calibrated_nop_signal[17] ... out f_NOPsp nop: NOP nop.respond out f_NOPsentrip[17] ... ... Figure 6: Neutron Overpower (NOP): Abstract Version – Synchronized Plant and Controller Figure 8 (p. 95) presents the complete5 TTM listing of the NOP unit as described above. The generate event of the plant non-deterministically updates the value of a global array that is shared with sensors attached to the NOP controller. The update is performed via the demonic assignment calibrated nop signals :: ARRAY[cal nop](N) (Lines 5 – 6). The NOP controller module (Lines 8 – 26) depends on two module instances (Lines 9–11). First, the controller depends on a plant p that generates 4Value of (a) is still greater than k NOPLoLimit, and similarly value of (d) is still smaller than k NOPHiLimit. 5For clarity, we present a version with one monitoring sensor. The full version with 18 sensors involves just declaring and instantiating additional dependent sensors. We also exclude definitions of constants and assertions. 92 Indexed Events & Synchronous Events in TTM an array of calibrated NOP signals (specified by the out array argument calibrated nop signal at Lines 4 and 47). Second, the controller depends on a sensor sensor 0 that monitors a particular signal value (specified by the in argument calibrated nop signal[0] at Lines 30 and 48) and provides feedback (specified by the share argument f NOPsentrip[0] at Line 31 and 48) for the central NOP controller to make a final decision (specified by the out argument c NOPparmtrip at Lines 14 and 49). Actions of the respond events of the NOP controller (Lines 19 – 24) and of its dependent sensors (Lines 36 – 43) correspond to the tabular requirements (Figure 5a and Figure 5b, respectively). We use primed variables in these actions to specify the intended flow of actions. Actions of the NOP sensor reference f NOP’ and calibrated nop signal i’ (Lines 37, 39, and 41) to indicate, that only after the instance p (in the same synchronous set) has written to these two variables can they be used to calculate the new value of f NOPsentrip[i]. Similarly, actions of the NOP controller reference f NOPsentrip’[j] (Lines 20 and 22) to indicate, that only after all sensor instances have written to this array can it be used to calculate the new value of c NOPparmtrip. We require that the respond event of the NOP controller, the respond events of its dependent sensors, and the generate event of the plant, are always executed synchronously (as a single transition). In declaring the controller event respond, we use a sync . . . as . . . clause to specify the events to be included in the synchronous set. When instantiating the NOP controller, we use a with . . . end clause to bind its dependent plant and sensor instances (Line 49). Finally, we rename the synchronized plant, controller, and sensor instances for references in assertions (Line 50). We check two invariant properties on this abstract version of NOP. First, as all dependent sensors have written to the shared array f NOPsentrip, the NOP controller responds instantaneously. ( ( ∃i : 0 ..N • f NOPsentrip[i] = e Trip )⇒ c NOPparmtrip = e Trip ∧ ( ∀i : 0 ..N • f NOPsentrip[i] = e NotTrip )⇒ c NOPparmtrip = e NotTrip )